Payment services provider methods in connection with personalized payments system

ABSTRACT

A method includes a processor receiving transaction information from a merchant device, which includes a transaction amount, merchant identifying information and customer addressing information. The processer transmits the merchant identifying information to a customer mobile device, and receives a payment transaction request to transfer funds from a customer account to a merchant. The processor translates the customer addressing information into a customer payment card account number, and the merchant identifying information into a merchant payment card account number. The processor then transmits the payment transaction request to the customer&#39;s issuer financial institution, which request includes the customer payment card account number, the transaction amount, and the merchant payment card account number.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation application of U.S. patentapplication Ser. No. 11/964,343 filed on Dec. 26, 2007, which claims thebenefit of U.S. Provisional Patent Application No. 60/977,260, filedOct. 3, 2007, which applications are incorporated herein in theirentirety by reference.

BACKGROUND

Embodiments disclosed herein relate to payment systems. In particular,some embodiments relate to methods, apparatus, systems, means andcomputer program products for implementing a payment system on the basisof a payment card system.

Payment card systems are in widespread use. A prominent payment cardsystem is operated by the assignee hereof, MasterCard InternationalIncorporated, and by its member financial institutions. FIG. 1schematically illustrates a typical transaction, as carried out in apayment system 100. To initiate the transaction, a customer (not shown)visits a retail store (not shown) operated by a merchant, selects goods(not shown) that he/she wishes to purchase, carries the goods to themerchant's point of sale terminal 104, and presents his/her payment card102 to the point of sale terminal 104. The point of sale terminal 104reads the customer's payment card account number from the payment card102, and then sends an authorization request to an acquirer financialinstitution (FI) 106 with which the merchant has a relationship. Theauthorization request includes the payment card account number and theamount of the transaction, among other information. The authorizationrequest is routed via a payment card system 108 (which may be, forexample, the well-known Banknet system operated by the assignee hereof)to the issuer financial institution 110 that issued the customer'spayment card 102. Arrows 112, 114 and 116 trace the path of theauthorization request from the POS terminal 104 to the issuer 110.

Assuming that all is in order, the issuer FI 110 transmits a favorableauthorization response to the point of sale terminal 104 through thepayment card system 108 and via the acquirer FI 106. (The path of theauthorization response from the issuer FI 110 to the POS terminal 104 istraced by arrows 118, 120, 122.) The transaction at the point of saleterminal 104 is then completed and the customer leaves the store withthe goods. A subsequent clearing transaction initiated by the merchantresults in a transfer of the transaction amount from the customer'spayment card account 124 to an account that belongs to the merchant. Thecustomer's payment card account 124 may be, for example, either a debitcard account or a credit card account. In the former case, the clearingtransaction results in the funds being debited directly from the account124. In the latter case, the clearing transaction results in a chargebeing posted against the account 124, and the charge subsequentlyappears on the customer's monthly credit card statement.

The foregoing description of the typical transaction may be consideredto be somewhat simplified in some respects. For example, a so-calledmerchant processing system (not shown) may be interposed between the POSterminal and the acquirer FI. As is familiar to those who are skilled inthe art, a merchant processing system may be operated by or on behalf ofthe merchant to form part of the communications path between theacquirer FI and a considerable number of POS terminals operated by themerchant. It is also often the case that a third party transactionprocessing service may operate to handle payment card transactions onbehalf of the acquirer and on behalf of a large number of other likefinancial institutions.

The present inventors have now recognized that an existing facility of apayment card system, referred to as a “payment transaction”, may beutilized to provide more convenient and flexible handling of purchasesof goods and other exchanges of value. Among other advantages, thetransactions described herein may be conducted such that the customerneed not disclose his/her payment card account number to the merchant.This may, in at least some circumstances, enhance the security of thecustomer's payment card account and lessen the possibilities formisappropriation of the payment card account number.

The novel use of payment transactions disclosed herein may also causetransactions to be conducted in such a manner that the customer may bemade fully aware of all transaction details before the customerinitiates the payment transaction. This may help to protect the customerfrom unintentionally authorizing erroneous or fraudulent payment cardtransactions, and may reduce the number of occasions in whichtransactions need to be reversed.

From the merchant's point of view, transaction techniques disclosedherein may save the merchant from having to enter into a relationshipwith an acquirer financial institution. This may be particularlyadvantageous for very small merchants or for merchants who do not havefixed places of business. Moreover, elimination of the “acquirer”function, as proposed herein, may result in savings in bank fees chargedto merchants.

The present inventors have also recognized that the novel transactiontechniques proposed herein present opportunities for novel value-addedservices which may be provided to customers, merchants and/or financialinstitutions.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present invention,and the manner in which the same are accomplished, will become morereadily apparent upon consideration of the following detaileddescription of the invention taken in conjunction with the accompanyingdrawings, which illustrate preferred and exemplary embodiments and whichare not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram that illustrates a conventional paymentsystem.

FIG. 2 is a block diagram that illustrates a transaction-handling systemin accordance with aspects of the present invention.

FIG. 3 is a block diagram that illustrates a point of sale terminal thatis shown in FIG. 2.

FIG. 4 is a block diagram that illustrates a customer's mobile telephonethat is shown in FIG. 2.

FIG. 5 is a block diagram that illustrates a transaction-handling systemaccording to some other embodiments.

FIG. 6 is block diagram that illustrates another embodiment of atransaction-handling system.

FIG. 7 is a block diagram representation of a computer that providespayment services in the system of FIG. 5 or 6.

FIG. 8 is a flow chart that illustrates a process that may be performedby a point of sale terminal or other merchant device in connection witha transaction handled as in FIG. 2, FIG. 5 or FIG. 6.

FIG. 9 is a flow chart that illustrates a process that may be performedby a customer's mobile device in connection with a transaction handledas in FIG. 2, FIG. 5 or FIG. 6.

FIG. 10 is a flow chart that illustrates a process that may be performedby the computer of FIG. 7.

FIG. 11 is a block diagram that illustrates a bill payment systemaccording to some embodiments.

FIG. 12 is a flow chart that illustrates a process that may be performedby a payment services provider computer in the system of FIG. 11.

FIG. 13 is a block diagram that illustrates a payroll disbursementsystem according to some embodiments.

FIG. 14 is a flow chart that illustrates a process that may be performedby a payment services provider computer in the system of FIG. 13.

FIG. 15 is a block diagram that illustrates still another embodiment ofa transaction-handling system.

FIG. 16 is a block diagram that illustrates yet another embodiment of atransaction-handling system.

FIG. 17 is a flow chart that illustrates a process that may be performedin a point of sale terminal that may serve as the merchant device shownin FIG. 2.

DETAILED DESCRIPTION

In general, and for the purpose of introducing concepts of embodimentsof the present invention, a payment card system payment transactioninitiated from a customer's device (such as a mobile telephone) isutilized to consummate a purchase of goods or services. In someembodiments, the transaction information, such as an amount due for thepurchase, and a code that identifies the merchant, may be entered intoor transmitted to the customer's device. In the former case, thetransaction information may be displayed by a merchant's device (e.g., aPOS terminal) to be read by the customer and manually entered by thecustomer into the customer's device. The customer may operate his/herdevice to initiate a request for a payment transaction via the issuer ofthe customer's payment card account. The request may direct thecustomer's issuer to implement a transfer of funds from the customer'spayment card account to the merchant's payment card account. The vehiclefor the funds transfer may be a conventional payment transaction of thetype now supported by at least one payment card system. The issuer ofthe customer's payment card account may cause the payment transaction tobe routed via the payment card system to the issuer of the merchant'spayment card account to be credited to the merchant's payment cardaccount. Upon authorization/completion of the payment transaction, themerchant's issuer may confirm to the merchant that the funds transferhas occurred (or is assured to occur subsequently during conventionalclearing operations), and in response to receiving the confirmation, themerchant may transfer ownership of the goods to the customer, or mayaccept the confirmation as payment for services rendered or to berendered to the customer.

In this arrangement, the payment card transaction enters the system viaa device operated by the customer and is initiated for routing from thecustomer's issuing financial institution, rather than originating fromthe merchant's POS terminal and the acquiring financial institution.Certain advantages of the rearranged and novel transaction flowdescribed herein have been alluded to above and will be discussed inmore detail below, along with other advantages and advantageousfeatures.

In other aspects, a payment services provider computer may facilitateand/or relay communications between the merchant's device and thecustomer's device, and/or between the customer's device and thecustomer's issuer, and/or between the merchant's issuer and themerchant. In some embodiments, the payment services provider computermay be operated by the payment card organization (e.g., the assigneehereof) that routes payment transactions from customer issuers tomerchant issuers and also routes purchase transactions from acquirers toissuers.

FIG. 2 is a block diagram that illustrates a transaction process inaccordance with aspects of the present invention. The various componentsshown in FIG. 2, and discussed below, may be a subset of a largersystem, indicated generally by reference numeral 200, for facilitatingpayments to merchants via credit cards, debit cards and the like. In theexample embodiment illustrated in FIG. 2, only components of system 200that operate with respect to a single transaction are shown.

The system 200 includes a merchant device 202, which may for example bea POS terminal or a suitably programmed mobile telephone or PDA(personal digital assistant) with communication capabilities. (Thelatter two possible embodiments of the merchant device may for examplebe particularly appropriate for merchants who operate without a fixedplace of business. Examples of such merchants may be flea marketsellers, artisans and crafters who sell their handiwork at craft fairs,itinerant merchants or merchants in third world marketplaces. For manymerchants in the categories described in this parenthetical, it may notbe practical or economic to enter into a conventional relationship withan acquirer FI.) If the merchant device is a POS terminal, the lattermay operate for the most part in a conventional manner or mayalternatively have functionality that actively contributes to the noveltransaction flow illustrated in FIG. 2. The POS terminal may be operatedin any type of business establishment or retail store, including a “momand pop” operation all the way up to a big box store that is part of amega retail chain. In some particularly helpful embodiments, themerchant device may be installed in a store such as a small antiques orcollectibles shop or the like in which the low volume of transactionsmay weigh against the expense and paperwork requirements involved inentering into a merchant-acquirer relationship with an FI.

Among other capabilities, and as will be described further below, themerchant device 202 may display transaction information to be read bythe customer (not shown) and manually inputted by the customer intohis/her mobile device 204. For example, the merchant device may displaythe total amount due for the transaction, and a merchant identificationnumber. Alternatively, the merchant ID may be permanently displayed on asticker affixed to the merchant device 202. (In some embodiments, themerchant identification number may be the account number that identifiesthe merchant's payment card account to which payment transactions are tobe routed. In other embodiments the merchant identification number mayrequire translation into such an account number, e.g., in a manner asdescribed below. If the merchant identification number is the merchant'spayment card number, steps may be taken to prevent misuse of the accountnumber. For example, the account corresponding to the account number maybe enabled only to have funds transfers credited thereto, but not toreceive charges via the payment card system, and with any transfers outof the account in question going into a companion account, with adifferent number, from which charges may be made.) The merchantidentification number may in some embodiments be the merchant's mobiletelephone number or another mobile identifier; this may be particularlyconvenient where the merchant device 202 is a mobile telephone.

In other embodiments, the merchant device 202 may have capabilities fortransmitting the transaction information to the customer device 204. Thetransmitting of the transaction information from the merchant device 202to the customer device 204 may be via wireless communication such as NFC(near field communication) or alternatively may be via a mobiletelephone network using text messaging or the like.

The customer's mobile device 204 may for example be a mobile telephonewith capabilities for initiating payment transactions in a payment cardsystem. Operation of a mobile telephone to initiate funds transfers viaa payment card system is for example described in commonly assigned U.S.patent application Ser. No. 11/836,945, filed Aug. 10, 2007, entitled“Payment Card Based Remittance System with Designation of Recipient ByMobile Telephone Number”, which is incorporated herein by reference. Asan alternative, the customer's mobile device 204 may be a PDA withcommunication capabilities. In some embodiments, the customer's mobiledevice may initiate a payment transaction by interacting with a websiteoperated by a payment services provider or by the issuer of thecustomer's payment card account.

FIG. 2 also shows, as included in the system 200, an issuer financialinstitution 206 which issued the customer's payment card account 208, apayment system 210 (such as the Banknet system referred to above) forrouting transactions from issuer to issuer (and also, e.g., fromacquirers to issuers), and an issuer financial institution 212 whichissued the merchant's payment card account 214. Blocks 206 and 212should also be understood to represent, respectively, computer systemsoperated by or on behalf of the customer issuer FI and the merchantissuer FI.

Arrows 216, 218, 220 trace the path of the payment transaction,requested from the customer's mobile device 204, as routed from thecustomer issuer 206, via the payment system 210 to the merchant issuer212. Arrows 222, 224 and 226 trace the path of acknowledgement messagesfrom the merchant issuer 212 via the payment system 210 and the customerissuer 206 to the customer's mobile device 204. Arrow 228 represents aconfirmation message sent from the merchant issuer 212 to the merchantdevice 202 to confirm that the payment transaction to pay for thepending sale has or will be credited to the merchant account 214. Uponreceiving the confirmation message 228 the merchant may allow the saleor other exchange of value to be completed.

Although only two issuing FIs, one mobile device and one merchant deviceare shown in FIG. 2, it should be understood that the system 200, in apractical embodiment, may include numerous issuing FIs all connected tothe payment system 210, a large number of merchant devices 202 and avery large number of customer mobile devices. Furthermore, the system210 preferably also operates in accordance with the conventionalpurchase transaction model illustrated in FIG. 1, and thus may include aconsiderable number of acquirer FIs as well. Of course, many if not allacquirer FIs may also be issuer FIs.

FIG. 3 is a block diagram of a POS terminal as provided in accordancewith aspects of the invention to serve (in some embodiments) as themerchant device 202 shown in FIG. 2. In some embodiments, the POSterminal 202 may be largely or entirely conventional in its hardwareaspects. Nevertheless, the POS terminal 202 may be programmed inaccordance with the aspects of the present invention to providefunctionality as described herein.

The POS terminal may include a processing element (or elements) such asthe processor 302 shown in FIG. 3. The processor 302 may for example bea conventional microprocessor, and may operate to control the overallfunctioning of the POS terminal 202. The POS terminal may also includeconventional peripheral components, in communication with and/orcontrolled by the processor 302, such as: (a) a keypad 304 for receivinginput from the human operator of the POS terminal; (b) a barcode reader306 for reading product barcodes from products brought to the terminalfor purchase; (c) a cash drawer 308 for storing cash received fromcustomers; (d) a magnetic stripe reader 310 for reading payment cardaccount numbers and related information from magnetic stripe paymentcards; (e) one or more displays 312 for providing output (e.g.,identifying products presented for purchase and their prices, indicatingsales tax due, indicating transaction subtotals and totals, etc.); (f) aprinter 314 for printing out sales receipts; (g) a wirelesscommunication terminal/proximity reader 316 for exchanging wirelessshort range communications/near field communications (NFC) withcontactless payment cards and/or with mobile telephone equipped withcontactless payment device capabilities; and (h) a communicationcontroller 318 for allowing the processor 302, and hence the POSterminal 202 to engage in communication over data networks with otherdevices (e.g., a merchant processing system (not shown), an acquirer(not shown) or its transaction processor (not shown), an issuer 212(FIG. 2) of the merchant's payment card account, etc. (In someembodiments, at least one of the displays 312 may be a touch screen, soas to provide an input function as well as an output function.) In someembodiments, the communication controller, or another communicationdevice coupled to the processor 302, may be provided to allow the POSterminal 202 to transmit and receive text messages or the like via amobile telephone network (not shown). In addition, the POS terminal 202may include one or more memory and/or data storage devices (indicatedcollectively at 320), which may comprise any combination of one or moreof a hard disk drive, RAM (random access memory), ROM (read onlymemory), flash memory, etc. The memory/data storage device(s) 320 maystore software and/or firmware that programs the processor 302 and thePOS terminal 202 to perform functionality as described herein. Further,the POS terminal may include one or more housings (not shown) whichcontain and/or support one or more of the other components shown in FIG.3.

Those who are skilled in the art will recognize that components 310, 316may be integrated in a single unit, and may include a display/touchscreen to allow for user interaction.

FIG. 4 is a block diagram of an example mobile telephone which may serveas the customer's mobile device 204 shown in FIG. 2. The mobiletelephone 204 shown in FIG. 4 may also (but need not) have capabilitiesfor functioning as a contactless payment device. In its hardware aspectsthe mobile telephone 204 may be entirely conventional, and indeed in itssoftware aspects it also may be conventional, and may provide novelfunctionality as described herein through interaction (via aconventional browser) with a web page that supports initiation ofpayment transactions. In other embodiments, however, novel functionalityas described herein may result at least partially from software and/orfirmware that programs the mobile telephone 204.

The mobile telephone 204 may include a conventional housing (indicatedby dashed line 402) that contains and/or supports the other componentsof the mobile telephone 204. The mobile telephone 204 further includesconventional control circuitry 404, for controlling over-all operationof the mobile telephone 402. Preferably the control circuitry 404 issuitably programmed to allow the mobile telephone 204 to engage in datacommunications and/or text messaging with other devices, and to allowfor interaction with web pages accessed via browser software, which isnot separately shown. Other components of the mobile telephone 204,which are in communication with and/or controlled by the controlcircuitry 404, include: (a) one or more memory devices 406 (e.g.,program and working memory, etc.); (b) a conventional SIM (subscriberidentification module) card 408; (c) a conventional keypad 410 (or touchscreen) for receiving user input; and (d) a conventional display 412(or, again, touch screen) for displaying output information to the user.

The mobile telephone 204 also includes conventional receive/transmitcircuitry 416 that is also in communication with and/or controlled bythe control circuitry 404. The receive/transmit circuitry 416 is coupledto an antenna 418 and provides the communication channel(s) by which themobile telephone 204 communicates via the mobile network (not shown).The mobile telephone 204 further includes a conventional microphone 420,coupled to the receive/transmit circuitry 416. Of course, the microphone420 is for receiving voice input from the user. In addition, aloudspeaker 422 is included to provide sound output to the user, and iscoupled to the receive/transmit circuitry 416.

The mobile telephone 204 may also include an integrated circuit (IC) orchipset 424 of the kind embedded in contactless payment cards. Forexample, the IC 424 is connected to an antenna 426 and operates so as tointeract with an RFID/NFC proximity reader of a POS terminal to providea payment card account number for a purchase transaction at the POSterminal. For example, the IC 424 may be designed/programmed to operatein accordance with the well-known “PayPass” standard (promulgated by theassignee hereof) for contactless payment applications.

FIG. 5 is a block diagram that illustrates an alternative embodiment(generally represented by reference numeral 200 a) of the system shownin FIG. 2. The system 200 a of FIG. 5 may include every component shownin FIG. 2, while also including a payment services provider (PSP)computer 502 that provides “on behalf” and/or value added services. Forexample, as seen from FIG. 5, the PSP computer 502 may exchangecommunications (by wireless communications and/or landlinecommunications) with each of the merchant device 202, the customer'smobile device 204 and the customer issuer 206. As will be seen, amongother functions, the PSP computer 502 may operate to relaycommunications between the merchant device 202 and the customer's mobiledevice 204, and between the customer's mobile device 204 and thecustomer issuer 206. Although only one PSP computer 502 is shown, inpractice it may be desirable to provide a considerable number of PSPcomputers, each serving a respective geographical region.

One potential advantage of the architecture shown in FIG. 5 is that thePSP computer may effectively provide front end processing on behalf ofthe customer issuer 206 so that the revised transaction flow proposedherein may be implemented with little or no modification to theoperations of the customer issuer 206.

The PSP computer or computers 502 may in some embodiments be operated bythe payment card association which also operates the payment system 210.Thus the PSP computer(s) 502 may be a vehicle for the payment cardassociation to enhance its service offerings for issuers, cardholdersand/or merchants.

FIG. 6 is a block diagram that illustrates still another embodiment(generally represented by reference numeral 200 b) of the systems shownin FIGS. 2 and 5. The system 200 b of FIG. 6 includes all of thecomponents shown in FIG. 5. However, in the system embodiment as shownin FIG. 6, the PSP computer 502 performs the additional function ofrelaying the payment transaction confirmation 602 from the merchantissuer 212 to the merchant device 202. Thus it could be said that thePSP computer 502 is performing “on behalf” services for both thecustomer issuer and the merchant issuer.

FIG. 7 is a block diagram representation of an example PSP computer 502which may be operated as part of the systems shown in FIG. 5 or FIG. 6

The PSP computer 502 may be conventional in its hardware aspects but maybe controlled by software to cause it to operate in accordance withaspects of the present invention.

The PSP computer 502 may include a computer processor 700 operativelycoupled to a communication device 701, a storage device 704, an inputdevice 706 and an output device 708.

The computer processor 700 may be constituted by one or moreconventional processors. Processor 700 operates to executeprocessor-executable steps, contained in program instructions describedbelow, so as to control the PSP computer 502 to provide desiredfunctionality.

Communication device 701 may be used to facilitate communication with,for example, other devices (such as customers' mobile devices 204,merchant devices 202, customer issuer computers 206 and/or merchantissuer computers 212). Communication device 701 may, for example, havecapabilities for sending and receiving messages over mobile telephonenetworks, as well as engaging in data communication over conventionalcomputer-to-computer data networks.

Input device 706 may comprise one or more of any type of peripheraldevice typically used to input data into a computer. For example, theinput device 706 may include a keyboard and a mouse. Output device 708may comprise, for example, a display and/or a printer.

Storage device 704 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g.,magnetic tape and hard disk drives), optical storage devices such as CDsand/or DVDs, and/or semiconductor memory devices such as Random AccessMemory (RAM) devices and Read Only Memory (ROM) devices, as well asso-called flash memory.

Storage device 704 stores one or more programs for controlling processor700. The programs comprise program instructions that containprocessor-executable process steps of PSP computer 502, including, insome cases, process steps that constitute processes provided inaccordance with principles of the present invention, as described inmore detail below.

The programs may include an application 710 that manages a process bywhich customers (i.e., cardholders) may enroll themselves and/or theirmobile devices with the PSP computer 502. In some embodiments, thecardholder enrollment process may allow the cardholders to enrollthemselves with the PSP computer 502 by accessing via their mobiledevices 204 a suitable web page hosted by the PSP computer 502. Theinformation gathered from the cardholder during the enrollment processmay include payment card account number and mobile telephone number (orother mobile identifier). The enrollment process may also require thecardholder to select a PIN (personal identification number) to be usedfor security purposes in connection with payment transactions to beinitiated by the cardholder via his/her mobile telephone and via the PSPcomputer 502. Other security measures may also be put in place. The PSPmay cooperate with the cardholder's issuing FI to provide securitymeasures that assure that the individual enrolling with the PSP computer502 is not an impostor.

The storage device 704 may also store an application 712 for managingenrollment of issuing FIs with the PSP computer 502. In someembodiments, actual enrollment of FIs with the PSP computer 502 may beperformed by data entry or file downloads managed by an administrativeemployee of the entity that operates the PSP computer 502. This mayoccur after person-to-person contacts between an employee of theoperator of the PSP computer 502 and an employee of the FI that isseeking enrollment. The FI may be enrolled as a customer issuer, amerchant issuer, or both. In some embodiments, the FI, as part of itsenrollment process, may also enroll its account holders (consumersand/or merchants) en masse with the PSP computer 502. Further, afterenrollment of an FI, it may thereafter, from time to time, feed to thePSP computer 502 enrollments of consumer and/or merchant holders ofpayment card accounts issued by the FI.

Another application that may be stored by the storage device 704 is forhandling individual transactions and is indicated by reference numeral714 in FIG. 7. Details of operation of the transaction handlingapplication 714 will be discussed hereinbelow, particularly withreference to FIG. 10.

Still another application 716 may be stored by the storage device 704and may operate in conjunction with the transaction handling application714 to provide special value added services to individual consumercardholders. Examples of such special services will be described below.

In addition, applications 718 and 720, both stored by the storage device704, respectively provide special value added services to merchants andto issuer FIs.

Reference numeral 722 in FIG. 7 identifies one or more databases thatare maintained by the PSP computer 502 on the storage device 704. Amongthese databases may be a consumer cardholder database, a merchantdatabase, an issuer database and a transaction database.

The application programs of the PSP computer 502 as described above, maybe combined in some embodiments, as convenient, into one, two or moreapplication programs. Moreover, the storage device 704 may store otherprograms, such as one or more operating systems, device drivers,database management software, web hosting software, etc.

FIG. 8 is a flow chart that illustrates an example sales transactionprocess that may be performed by the merchant device 202 (FIGS. 2, 5, 6)in accordance with aspects of the present invention.

At 802 in FIG. 8, information to define the transaction is entered intothe merchant device 202. For example, if the merchant device is aconventional POS terminal, at least some of the transaction informationmay be entered by using a barcode scanning component of the POS terminalto scan the product identification barcodes from one or more itemspresented for purchase by the customer. In accordance with conventionalpractices, upon reading the product barcodes, the POS terminal retrievesthe prices for the items to be purchased (and possibly the productdescription and other information as well) and generates a subtotal anda total (e.g., including sales tax) for the sale transaction. Some orall of the steps referred to in the previous sentence may be consideredto be “generating transaction data” and are represented at 804 in FIG.8. Moreover, as will be seen, for subsequent stages in the transaction,a set of transaction data for the transaction in question may includeidentifying codes (e.g. ID numbers) for either or both of the POSterminal and the merchant who is the proprietor of the POS terminal.Thus generating the transaction data may include generating a set ofinformation for the transaction that includes the amount due for thetransaction and one or both of the merchant identifier and the POSterminal identifier. Generating the transaction data may also includedgenerating and including in the set of data a unique identifying numberfor the transaction (transaction identifier/reference number). In somecases, the transaction data generated at 804 may also include line itemsand/or product descriptions.

From the “first world” (possibly mega-retailer) example embodiment ofsteps 802-804 as described up to this point, the discussion will nowturn to a radically different example embodiment, suitable for use evenin a developing country. Assume, then, that the merchant device 202 is asuitably programmed mobile telephone owned by an individual merchant.The merchant may, for example, be a farmer or a dealer in produce,handicrafts, second-hand or new clothing or anything else commonlytraded by individual entrepreneurs in the markets of third worldcountries. It may be assumed further that the merchant conducts his orher business in a stall or at a table in an open air market, withoutelectricity or any other modern convenience. Further assume that themerchant is “banked” only to the extent of holding a payment cardaccount issued by an FI and by being enrolled as a merchant with respectto the payment card account (i.e., the FI in question does not act as apurchase transaction acquirer for the merchant, in this scenario). Insuch a situation, the entry 402 of the purchase information may consistsimply in the merchant entering a sales transaction total amount dueinto the merchant device/mobile telephone 202 via the keypad of thedevice 202. (The total amount due may for example have been arrived atby the merchant adding in his/her head—or on a separate calculator—theprices of the items purchased, or may be calculated by a calculatorfunction in the mobile telephone 202 (another example embodiment of 804)from individual item prices manually entered (another example embodimentof 802) one after the other into the mobile telephone by the merchant.)The generating of the transaction data may consist in assembling atransaction data set consisting of just two items of data—amount due,and the mobile telephone number assigned to the merchant device/mobiletelephone 202. These two data items may form the payload of a textmessage/SMS message or other type of information message to be sent tothe customer's mobile telephone (mobile device 204). (Alternatively, themobile telephone network may operate so that, by a “caller ID” featurethe mobile telephone number assigned to the merchant device 202 isautomatically provided to the customer mobile telephone 204 when thetext message or other information message is received.) In any event,the merchant may receive (step 806, FIG. 8) from the customer, by oralface to face communication, the mobile telephone number assigned to thecustomer's mobile telephone 204 and may enter that number into themerchant's mobile telephone 202, so that the transaction information maybe transmitted (step 808, FIG. 8) from merchant device 202 to customermobile device 204. (For definitional purposes, transmission of thetransaction information should be understood to encompass provision ofthe merchant mobile telephone number from the merchant mobile telephoneto the customer mobile telephone via a “caller ID” feature of the mobilenetwork. It should also be noted that the merchant mobile telephonenumber may serve as a merchant identifier for purposes of the customer'ssubsequent initiation of a request for a payment transaction.)

As will be expected from previous discussion, and as will be describedfurther below (e.g., in conjunction with FIG. 9), the customer may nextoperate his mobile telephone 204, using the transaction informationtransmitted thereto from the merchant device 202, to request that apayment transaction be carried out in the payment system (e.g., system200, FIG. 2) to transfer the transaction amount from the customer'spayment card account 208 to the merchant's payment card account 214.While this is occurring, the merchant/merchant device 202 may wait(block 810, FIG. 8) to receive the confirmation 228 (FIG. 2) that thefunds transfer has been or will be accomplished via the channels of thepayment card system 210. Once the confirmation is received by themerchant device 810 (the whole process may require only a few seconds),the merchant transfers title in the purchased items to the customer, andthe transaction is complete (FIG. 8—block 812).

Before returning to the “mega-retailer” scenario with which we openeddiscussion of FIG. 8, there will be a brief mention of advantagesprovided by aspects of the present invention in the above-describedthird world market scenario. Perhaps most important, the process of FIG.8 is cashless, so that neither the merchant nor the customer takes onthe often large risks of carrying and holding cash in a third worldenvironment. Also, this process leverages on the already existingprevalence of mobile telephones among third world merchants andconsumers. The banking relationships required by the participants arealso such as may be established and maintained at relatively low cost,thus minimizing the economic barriers to adoption. Still further, thesystem is an open one, in the sense that the parties need not have arelationship with the same financial institution/service provider, butneed only have low level banking relationships with respective FIs thatbelong to a widespread payment card system such as that organized by theassignee hereof. Finally, the parties do not need to even use the samemobile network operator (MNO), so long as their respective MNOs areinteroperative.

Returning now to the previous example in which the merchant device 202was a conventional POS terminal, it will be recalled that the POSterminal 202 had received entry of purchase information (802 in FIG. 8)and had generated transaction data for the sales transaction (804 inFIG. 8). It may next possibly be the case (806, FIG. 8) that thecustomer will orally advise the POS terminal operator of the customer'smobile telephone number (or other mobile identifier), so that the POSterminal operator may enter the customer's mobile telephone number (orother mobile identifier) into the POS terminal, as a prelude to the POSterminal transmitting the transaction data (808 in FIG. 8) to thecustomer's mobile device. (As suggested above, the transmission may be atext message/SMS or the like.) However, in a high-volume retailenvironment, it may be preferred not to take the time for such an oralexchange of information and manual entry of the telephone number.Instead, for example, the POS terminal may transmit the transactioninformation to the customer's mobile device via NFC (near fieldcommunication) or the like. As another alternative embodiment of 808,the POS terminal may display the transaction information (e.g., totalamount due and merchant/POS terminal identifier) for the customer tomanually enter into his/her mobile device. (The merchant/POS identifiermay even be permanently displayed on a sticker or placard, for example.)Although the NFC (or such) example embodiment of step 808 may bepreferable for a high volume environment, any of the other alternativesset forth above may be quite appropriate for a retail establishment inwhich the transactions are relatively infrequent.

In still another embodiment of step 808, the POS terminal 202 maytransmit the transaction information to a payment services providercomputer 502 (FIGS. 5 and 6), which may in turn relay the information tothe customer's mobile device 204. Presumably in this embodiment of step808 it may be necessary for the POS terminal to receive, either bywireless communication or by operator data entry, a mobile telephonenumber or other addressing information for the customer's mobile device204. In this embodiment, the POS terminal may include the mobiletelephone number or other addressing information for the customer'smobile device 204 in the transmission to the payment services providercomputer 502, so that the payment services provider computer 502 may inturn route the transaction information to the customer's mobile device204. In another variation, the POS terminal 202 may include atransaction reference number in the transmission to the payment servicesprovider computer 502, and may also transmit the transaction referencenumber to the customer's mobile device 204. (Or, the POS terminal 202may display the transaction reference number, and the customer may enterthe transaction reference number into the mobile device 204.) Thecustomer may then use the mobile device 204 to call in to the paymentservices provider computer 502 and use the transaction reference numberto identify to the payment services provider computer 502 thetransaction information to be relayed from the payment services providercomputer 502 to the customer's mobile device 204.

In still another variation, the transaction reference number may beunique only to the merchant, so that the merchant identifier may also beneeded to index the transaction information within a database maintainedby the payment services provider computer 502. The merchant identifiermay be transmitted to the customer's mobile device 204 by the POSterminal 202 or may be displayed by the POS terminal 202 for thecustomer to read and enter into the mobile device 204. As an alternativeto the possibilities stated in the previous sentence, when the customercalls in to the payment services provider computer 502 with the mobiledevice 204, the mobile device 204 may report its current location (viaGPS—Global Positioning System—data or the like) to the payment servicesprovider computer 502; the payment services provider computer 502 maythen infer, from the location information, the identity of the merchantat which the customer and his/her device are currently located. For sucha purpose, the payment services provider computer 502 may maintain adatabase of merchant locations.

In some embodiments, the transaction information transmitted by the POSterminal 202 to the customer's mobile device 204 or to the paymentservices provider computer 502, as the case may be, may include lineitem information that identifies individual product items that areincluded in the current sale transaction.

Even in the case of the mega-retailer example, the process of FIG. 8 mayend as in the third world market example, with the merchant device 202(currently assumed to be a POS terminal) waiting (810 in FIG. 8) toreceive from the merchant's FI (or a PSP acting as an intermediary)confirmation of the payment transaction in favor of the merchant'saccount 214. The transaction is then completed (step 812). For example,the merchant releases goods purchased to the customer and/or uses themerchant device 202 to print a receipt for the transaction and gives thereceipt to the customer.

It should be understood that, for relatively small and/or mobilemerchants, the third world model described above may be convenientlyadopted even in a developed country, and that the merchant device 202accordingly may be a mobile telephone in the case of any merchant wholacks or prefers not to use a POS terminal, regardless of the merchant'slocation.

According to one possible feature of the above described merchant deviceprocess, and although not indicated in FIG. 8, the process could have atime-out feature such that the merchant device aborts the transaction ifthe payment transaction confirmation is not received within apredetermined waiting period.

FIG. 9 is a flow chart that illustrates a process that may be performedby the customer's mobile device 204 in connection with a transactionhandled as in FIG. 2, FIG. 5 or FIG. 6.

At 902 in FIG. 9, the mobile device 204 may receive the transactioninformation or the transaction information may be entered into themobile device 204 by the customer's interaction with the user interfaceoffered by the mobile device 204. If the mobile device receives thetransaction information, this may occur by wireless transmission fromeither the merchant device 202 or from the payment services provider502. In some embodiments, the transaction information and/or otherinformation received by the customer's mobile device 204 may (asindicated at 904 in FIG. 4) include the name of the merchant. Forexample, the name of the merchant may be transmitted to the customer'smobile device 204 by the payment services provider 502 or by thecustomer's issuing FI 206. In effect, the payment services provider 502may serve as a trusted third party to verify the identity of themerchant and to protect the customer from dealing with an impostor. Thepayment services provider may be able to vouch for the merchant becausethe merchant has gone through an enrollment process with the paymentservices provider or with an FI that is trusted by the payment servicesprovider. In this way, the customer may be assured of the merchant'sidentity before the customer initiates the payment transaction.

Next, at 906, the customer's mobile device 204 generates a request for apayment transaction. In some embodiments, the request for a paymenttransaction includes the transaction amount and a merchantidentification code. The request for the payment transaction may alsoinclude an identification code or number that identifies the customer.This code or number may be explicitly included in the request or may beimplicitly generated as, e.g., a caller identification that identifiesthe mobile telephone number assigned to the mobile device 204. Theidentifier for the customer may for example thus be the mobile telephonenumber assigned to the mobile device 204 or the payment card accountnumber that identifies the customer's payment card account that is to beused to fund the payment transaction. In some embodiments, the merchantidentification code may be one or more of a mobile telephone numberassigned to the merchant device 202, or the payment card account numberthat identifies the merchant's payment card account that is to becredited by the payment transaction, or an identifier that otherwiseidentifies the merchant, such as a code used to index the merchant'srecord in a database maintained by a payment services provider computer502. In addition, an identifier for the particular merchant device 202may also be included in the payment transaction request.

In other embodiments, the request need only refer to the transaction bya transaction reference number, with the payment services providercomputer 502 being relied upon to look up the other transactioninformation, such as merchant ID and transaction amount.

At 908, the customer's mobile device 204 transmits the request for apayment transaction. In some embodiments, the mobile device 204transmits the request for a payment transaction to the FI 206 (FIG. 2)which issued the customer's payment card account. In other embodiments,the mobile device 204 transmits the request for a payment transaction toa payment services provider, as in FIGS. 5 and 6.

In some embodiments, the request for a payment transaction mayexplicitly include the customer's payment card account number, themerchant's payment card account number and the amount of the requestedpayment transaction, in which case the request may be handled in astraightforward manner by the customer's FI 206. In other embodiments,the customer and/or the merchant may be identified by their respectivemobile telephone numbers or in another manner apart from their paymentcard account numbers. If so, the customer's FI may translate thecustomer's mobile telephone number (whether explicitly or implicitly (bycaller ID) included in the request) into the customer's payment cardaccount number, and the payment system 210 may translate the merchant'smobile telephone number into the merchant's payment card account numberand may route the transaction accordingly. In other embodiments, thepayment services provider computer 502 may perform one or both of thetranslations referred to in the previous sentence.

In some embodiments, the customer's mobile device, and hence thecustomer, may be identified by a SIM identifier or the like rather thanby mobile telephone number.

In some embodiments, the payment transaction request transmitted by thecustomer's mobile device 204 may include line item information thatidentifies individual product items that the customer is purchasing.

In some embodiments, an authentication procedure (block 910) may beincluded in the process of FIG. 9. This may go beyond requiring thecustomer to enter a PIN in order to access the payment transactionrequest function. For example, the customer's issuer 206, and/or thepayment services provider computer 502 acting on behalf of thecustomer's issuer, may selectively require additional authentication inthe case of certain transactions, based on various criteria. Thesecriteria may include, for example, the amount of the requested paymenttransaction, the time of day and/or day of the week, the item(s) beingpurchased, the identity of the customer and/or the identity of themerchant. Recent or past account activity or inactivity may also betaken into consideration in determining whether to requireauthentication.

The authentication procedure may include an exchange of text messagesand/or electronic mail messages (or another type of information message)via the customer's mobile device 204 or a telephone conversation via thecustomer's mobile device 204. The exchange of messages and/or thetelephone conversation may be handled by a human employee of thecustomer issuer 206 and/or the payment services provider 502.Alternatively, the exchange of information messages may be automaticallyconducted by computer on the part of the customer issuer 206 and/or thepayment services provider 502, or the customer may be required to“converse” with an automated voice response system operated by thecustomer issuer 206 and/or the payment services provider 502. Theexchange of messages or telephone conversation may include issuing a“challenge” to the customer, such as requiring the customer to provideone or more items of security information (e.g., date of birth, mother'smaiden name, birthplace, home telephone number, home address, SocialSecurity number, etc.).

In other embodiments, and assuming that the customer's mobile device isa mobile camera-phone, the authentication procedure may call for thecustomer to use the mobile device to take his/her picture and send it tothe authenticating authority so that an individual employee of theauthenticating authority may compare the picture with another picture ofthe customer that is previously on file.

In some embodiments, demographic information about customers ascollected by the customers' mobile network providers may be provided tomerchants for market research purposes.

In some embodiments, the process of FIG. 9 may include value addedservices (block 912), provided to the customer by either of both of thecustomer's issuer 206 and the payment services provider 502. These valueadded services may be such as cannot readily be provided in theconventional transaction flow depicted in FIG. 1.

For example, if the customer requests a payment transaction at a timewhen the customer has exceeded his/her credit limit or has depletedhis/her debit card account, the customer's issuer 206 (or the paymentservices provider acting on behalf of the customer's issuer 206) mayrespond to the request for a payment transaction with a message (sent tothe customer's mobile device 204) offering to make an overdraft orcredit facility available to the customer, so that the request for apayment transaction can be honored.

According to another special service, the customer's issuer 206 and/orthe payment services provider 502 (in this case not necessarily actingon behalf of the customer's issuer 206) may present the customer (via amessage or messages to the mobile device 204) with one or morepromotional offers and/or virtual coupons which the customer may availhimself/herself with to fund at least a portion of the paymenttransaction. For example, based on the identity of the merchant (and thecustomer not previously being enrolled with the merchant), the paymentservices provider 502 may offer on behalf of the merchant that a portionof the payment transaction will be funded by the merchant if thecustomer enrolls in the merchant's customer loyalty program.

In another example, an offer provided by a third party may be contingenton the customer adding an additional item to the pending transaction.For example, say the customer is purchasing an item that requiresinstallation, and is also purchasing a warranty on the item. Themanufacturer or warranty provider may offer to be a source of fundingfor a portion of the purchase price, contingent on the customerpurchasing installation services for the item from the merchant. Thisoffer benefits the merchant, by increasing the merchant's installationbusiness; benefits the customer, by reducing the customer's cost for thetransaction; and benefits the manufacturer/warranty provider byincreasing the likelihood that installation will be performed correctly,thereby decreasing the likelihood of a warranty claim.

In still another example, suppose that the customer is purchasing anitem that requires installation during a particularly busy time periodsuch as the holiday season. In this case, a third party installationprovider may offer to partially fund the transaction on the conditionthat the customer agree to defer installation until after the busyperiod is over.

Alternatively, the customer's issuer 206 (or the payment servicesprovider 502 acting on behalf of the customer's issuer 206) may offer tofund part of the payment transaction if the customer agrees to open adeposit account with the customer's issuer. (Additional examples and afurther discussion of “split-funding” of payment transactions will bedescribed below in conjunction with FIG. 15.)

At 914 in FIG. 9, the customer's mobile device 204 receives a messagethat confirms that the payment transaction has been executed (possiblysubject to a subsequent clearing operation). The customer's mobiledevice 204 may for example receive this confirmation message from thecustomer's issuer 206 or from the payment services provider computer502. However, in alternative embodiments step 914 may be omitted, andthe customer may effectively be informed that the payment transactionhas gone through based on the merchant's willingness to complete thesales transaction, release the goods to be purchased, issue a receipt,etc. in response to the merchant device 202 receiving confirmation ofthe payment transaction.

FIG. 10 is a flow chart that illustrates a process that may be performedby the payment services provider computer 502.

At 1002 in FIG. 10, the payment services provider computer 502 receivesthe transaction information from the merchant device 202. As will beappreciated from previous discussion, the transaction information mayinclude the amount of payment to be made for the transaction andmerchant identifying information, such as a merchant number or a mobiletelephone number that was assigned to the merchant device 202. (As notedabove, the merchant device 202 may be a mobile telephone, oralternatively a POS terminal or PDA.) In some cases, the transactioninformation also includes a transaction reference number assigned by themerchant device, for use in subsequent communications among the paymentservices provider computer 502, the merchant device 202 and thecustomer's mobile device 204. The transaction information may alsoinclude details of the transaction, including information thatidentifies the items purchased, line item pricing, promotional offers orcoupons made available by the merchant, etc. The transaction informationmay also include addressing information to allow the payment servicesprovider computer 502 to contact the customer's mobile device 204.Further, the transaction information may include particulars about themerchant device and/or capabilities of the merchant device (e.g.,whether the merchant device is a POS terminal or a mobile phone; if thelatter, what the capabilities are of the mobile phone; whether themerchant device is NFC/RFID capable). Another category of transactioninformation may include encryption- and/or authentication-relatedinformation, such as the merchant's public keys for digital signatures,etc. Still another category of transaction information may includeinformation that identifies the merchant's physical location, or thelocation of the merchant device. The addressing information may forexample be a mobile telephone number assigned to the customer's mobiledevice 204.

At 1004 in FIG. 10, the payment services provider computer 502 may usethe addressing information for the customer's mobile device 204 totransmit at least some of the transaction information to the customer'smobile device 204. In some embodiments, the payment services providercomputer 502 may have looked up the name of the merchant based on themerchant identifying information received from the merchant device 202,and the payment services provider computer 502 may append the name ofthe merchant to transaction information that the payment servicesprovider computer 502 transmits to the customer's mobile device.

At 1006 in FIG. 10, the payment services provider computer 502 receivesa request for a payment transaction from the customer's mobile device204. In some embodiments, the request may consist entirely of anindication to the effect of “yes, I want to go ahead with thetransaction” plus the transaction reference number. In otherembodiments, the request for the payment transaction, as received fromthe customer's mobile device, may include more detail, such astransaction amount (amount to be transferred by the paymenttransaction), merchant identifier (e.g., merchant mobile telephonenumber) and customer identifier (e.g., customer mobile telephonenumber—included explicitly in the request or implicitly by caller ID, orcustomer's payment card account number, or another code or referencethat identifies the customer).

At 1008, in some embodiments, the payment services provider computer 502may undertake an authentication procedure or procedures, as describedabove in connection with step 910 in FIG. 9, and/or the payment servicesprovider computer 502 may offer or provide certain special services,promotional offers, credit offers, as described above in connection withstep 912 in FIG. 9. In some cases, the special services, for example,may be initiated earlier in the process, such as in conjunction withstep 1004. That is, the transaction information that the paymentservices provider computer 502 transmits to the customer's mobile deviceat 1004 may include offers of special services, etc.

Another type of special service that may be provided by the paymentservices provider computer, and not mentioned up to now, may entailenforcing restrictions on usage of the customer's payment card account208. Consider, for example, a payment card account set up by a parentfor his/her college student child. The parent may be able to set uprestrictions as to (a) which merchants the payment card account may beused to pay (college bookstore and dining hall only, e.g.), and/or (b) amaximum dollar amount of transactions allowed per period of time (e.g.,$100.00 per week). The payment card account may be restricted as invalidfor purchase transactions or other transactions that are not paymenttransactions as described herein, so that the payment services providercomputer (in enforcing the parental restrictions) effectively may havecomplete control over the use of the payment card account.

In another embodiment, the customer's issuing FI 206, rather than thepayment services provider computer, may enforce restrictions of the sortdescribed in the previous paragraph.

In other embodiments, when the child requests a payment transaction of akind that is not permitted by existing parental restrictions, the PSPcomputer 502 or the customer FI 206 may send a real time inquiry messageto the parent, asking whether the parent will allow the particulartransaction. If the parent approves the requested payment transaction,the PSP computer 502 or the customer FI 206 proceeds with the requestedpayment transaction. If the parent does not approve, the requestedpayment transaction is declined. With this arrangement, it will beappreciated that the child may phone the parent ahead of time to alertthe parent that the child intends to request a payment transaction thatfalls outside the established restrictions.

In another example in which a restricted use payment card account may beuseful, consider the case of a well-to-do individual who hires apersonal assistant to help in managing his/her household. The employingindividual may set up a restricted-use payment card account for theassistant to use in paying some of the household expenses, but againlimited to certain suppliers (e.g., grocery store, house-cleaningcontractor, utility companies, etc.) and/or to a maximum amount perperiod of time.

At 1010, the payment services provider computer 502, to the extentrequired, may translate the customer identifying information (e.g.,customer's mobile telephone number) into the customer's (funding)payment card account number for the requested payment transaction, andthe payment services provider computer 502 may translate the merchant'sidentifying information (e.g., the merchant's mobile telephone number)into the payment card account number for the merchant's account to whichthe payment transaction is to be routed.

Next, at 1012, the payment services provider computer 502 may forwardthe request for the payment transaction to the customer's issuing FI206. As forwarded by the payment services provider computer 502, therequest for the payment transaction may include all information that thecustomer's issuing FI 206 may need to process the payment transaction ina conventional manner. Thus, the request as forwarded by the paymentservices provider computer 502 to the customer's issuing FI 206 mayinclude the payment card account number for the funding payment cardaccount (issued by the FI 206 to the customer), the amount of thepayment transaction, and the payment card account number for themerchant's payment card account to which the payment transaction is tobe routed.

In some embodiments, the payment services provider computer 502 may haveno more involvement in the transaction. For example, the paymenttransaction may proceed from the customer's FI 206 to the merchant's FI212 via the payment system 210, and the merchant's FI 212 may provide aconfirmation 228 (FIG. 5) to the merchant device 202 to allow forcompletion of the sales transaction between the merchant and thecustomer. In other embodiments, however, the payment services providercomputer 502 may be in the communication path between the merchant FI212 and the merchant device 202, as illustrated in FIG. 6. That is, andas indicated at 1014 in FIG. 10, the payment services provider computer502 may receive from the merchant FI 212 an authorization response toindicate that the merchant's account exists and is in a proper status toreceive the payment, so that the payment transaction will go through (orhas gone through). Then, at 1016 in FIG. 10, the payment servicesprovider computer 502 may provide a confirmation of the paymenttransaction to the merchant device 202 to allow for completion of thesales transaction. Also, and optionally, the payment services providercomputer 502 may provide confirmation of the payment transaction to thecustomer's mobile device 204 (step 1018). In some embodiments, tofacilitate at least steps 1014 and 1016, the request for the paymenttransaction, as forwarded from the payment system 210 to the merchant FI212, may include a transaction reference number that the merchant FI212, in turn, includes in the authorization response. In that way, thepayment services provider computer 502 is able to retrieve its record ofthe transaction upon receiving the authorization response, and is ableto provide a proper confirmation message to the merchant device 202.

FIG. 11 is a block diagram that illustrates a bill payment system 1102according to some embodiments. The bill payment system 1102 may have thefollowing components in common with the payment system 200 b shown inFIG. 6: (a) mobile device 204 (customer's mobile device); (b) paymentservices provider computer 502; (c) issuing FI 206 (for the customer'spayment card account); (d) payment system 210; and (e) receiving/issuingFI 212. However, instead of the merchant device 202 shown in FIG. 6, thebill payment system 1102 includes a service provider computer 1104operated by or on behalf of a service provider such as a public utility,a daily or periodical publication or any other entity with a largecustomer base that it regularly sends bills to. Moreover the receivingissuer FI 212 in the case of the system 1102 receives paymenttransactions for the service provider rather than for a retail merchant.

FIG. 12 is a flow chart that illustrates a process that may be performedby the payment services provider computer 502 in the bill payment system1102 of FIG. 11.

At 1202 in FIG. 12, the payment services provider computer 502 receivesa batch of billing information from the service provider 1104 (forexample, an electric utility company). Let us assume that the billinginformation concerns monthly electricity bills from the service provider1104 to its residential subscribers (or at least for those who havesigned up for bill payment through the system 1102 illustrated in FIG.11). The billing information may contain numerous records, each of whichrepresents a single bill. Each record may contain, for example, theamount of the bill, a customer identifier for the customer in question,and the mobile telephone number for the customer in question (oralternatively, the mobile telephone number may serve as the customeridentifier), a record number, etc. (In some embodiments, the serviceprovider 1104 may also send the billing information directly to thecustomer's mobile device 204, as indicated by arrow 1106 in FIG. 11.)

At 1204 in FIG. 12, the payment services provider computer 502 transmitsthe billing information in each record to the mobile device 204 (onlyone shown) that belongs to the respective customer for the billingrecord. In effect, the information transmitted to the customer's mobiledevice may indicate, “Your monthly electric bill is $XXX.XX. Do you wishto pay with your credit/debit card?” Assuming that the customerindicates “yes” via suitable interaction with the mobile device 204,then at 1206, the payment services provider computer 502 effectivelyreceives a request from the customer for a payment transaction to settlethe bill.

At 1208, the payment services provider computer 502, to the extentrequired, may translate the customer identifying information (e.g., thecustomer's mobile telephone number or the customer's account number withthe service provider) into the customer's (funding) payment card accountnumber for the requested payment transaction, and the payment servicesprovider computer 502 may translate the service provider's identifyinginformation into the payment card account number for the serviceprovider's payment card account to which the payment transaction is tobe routed. In one alternative, the payment services provider computer502 may be programmed to automatically interpret the customer'saffirmative response to the question transmitted at 1204 as a request toinitiate a payment transaction to the service provider's payment cardaccount number that the payment services provider computer 502 hadpreviously associated with the batch of billing information received at1202. In fact, the batch of billing information may have includedinstructions from the service provider 1104 as to the payment cardaccount number for the service provider's payment card account 214 (FIG.11).

It will be appreciated that step 1208 may typically occur with respectto each customer to whom the billing information was sent at 1204.

At 1210, the payment services provider computer 502 may forward thecustomers' request for payment transactions to the customers' variousissuing FIs 206 (only one shown in FIG. 11). As forwarded by the paymentservices provider computer 502, the requests for payment transactionsmay include all information required for the customers' issuers 206 toprocess the payment transactions in a conventional manner. Thus, therequests forwarded by the payment services provider computer 502 eachmay include the payment card account number for the customer's paymentcard account 208, the amount of the payment transaction (amount due onthe bill), and the payment card account number for the serviceprovider's payment card account 214.

In some embodiments, the payment services provider computer 502 may haveno more involvement in the service provider's billing activities for thecurrent billing cycle. For example, the payment transaction may proceedfrom the customer's FI 206 to the service provider's FI 212 via thepayment system 210, and the service provider 1106 may receive aconfirmation message or report from its FI 212 as to payments received.However, in an alternative arrangement, as illustrated in FIG. 11 andstep 1212 in FIG. 12, the payment services provider computer 502 mayreceive, from the service provider's FI 212, individually or inbatches/reports, confirmations or authorization responses from theservice provider's FI 212 to indicate that the payment transaction hadgone through or would do so, via normal clearing activities. Then at1214 in FIG. 12, the payment services provider computer 502 may provideconfirmations of the payment transactions (individually or in batches)to the service provider computer 1104. In addition, as indicated at1216, the payment services provider computer 502 may confirm the paymenttransaction and settlement of the bill to each customer's mobile device204.

FIG. 13 is a block diagram that illustrates a payroll disbursementsystem 1302 according to some embodiments.

The payroll disbursement system 1302 may include an employer computer1304 operated by or on behalf of an employer organization which pays itsemployees via the system 1302. The employer may, but need not, have aconsiderable number of employees on its payroll. Block 1306 in FIG. 13represents a mobile telephone or home computer that belongs to anemployee of the employer.

The payroll disbursement system 1302 further includes a payment servicesprovider computer 502 and a payment system 210 as in systems shown inFIG. 2, 5, 6 or 11, for example. In addition, the payroll disbursementsystem includes an FI 1308 that issued a payment card account 1310 tothe employer, and issuing FIs 1312 (only one shown) that issued paymentcard accounts 1314 to employees.

FIG. 14 is a flow chart that illustrates a process that may be performedby the payment services provider computer 502 in the system of FIG. 13.

At 1402 in FIG. 14, the payment services provider computer 502 receivesa batch of payroll disbursement information from the employer computer1304 (or alternatively from a payroll services provider retained by theemployer). The payroll disbursement information may include a number(potentially a large number) of records, each representing wages orsalary to be paid to a respective employee for the current employmentperiod. Each record may contain, for example, a record number, the netamount that is being paid to the employee in question, an employeeidentification number (which could be the employee's Social Securitynumber), the mobile telephone number for the employee in question, or apayment card account number that identifies the payment account to whichthe employee's wages or salary are to be disbursed. (In someembodiments, the employer may also provide a paystub or virtual paystubdirectly to the employee device, as indicated by arrow 1316.)

At 1404, the payment services provider computer 502, to the extentrequired, may translate the employee identifier into the payment cardaccount number for the employee's payment card account to which thewage/salary payment is to be routed.

At 1406 in FIG. 14, the payment services provider computer 502 mayforward, to the employer's issuing FI 1308, requests for paymenttransactions with respect to each of the wage/salary payments indicatedby the batch of payroll information received at 1402. For example, eachof the requests for a payment transaction may include the amount of thepayment, the payment card account number that identifies the employer'spayment card account 1310 from which the payment transaction is to befunded, and the payment card account number that identifies theemployee's payment card account to which the payment transaction is tobe routed.

In some embodiments, the payment services provider computer 502 may haveno more involvement in the payroll disbursement process. For example,the payment transactions may proceed from the employer's FI 1308 to theemployees' FIs 1312 via the payment system 210, and either noconfirmations of the payment transactions are provided to the employees,or the employees receive confirmations of the payment transactions fromtheir individual FIs 1312. Alternatively, however, and as indicated at1408 in FIG. 14, the payment services provider computer 502 may receive,from each of the employees' FIs 1312, confirmations or authorizationresponses to indicate that the payment transactions had gone through orwould do so (via normal clearing activities). Then, at 1410, the paymentservices provider computer 502 may provide confirmations of the paymenttransactions to the employee devices 1306. (Although not indicated inFIG. 14, the payment services provider computer 502 may also provideconfirmations of the payment transactions to the employer computer1304.)

FIG. 15 is a block diagram that illustrates still another embodiment ofa transaction-handling system, indicated by reference numeral 200 c.

For example, the transaction-handling system 200 c of FIG. 15 may haveall of the components shown in FIG. 5, including the merchant device202, the customer's mobile device 204, the payment services providercomputer 502, the customer's issuing FI 206, the payment system 210 andthe merchant's issuing FI 212. In addition, the system 200 c may includea computer that is represented by block 1502 in FIG. 15 and that isoperated by an entity that, at least on occasion, may partially orcompletely fund payment transactions instead of the payment transactionsbeing totally funded from the customer's payment card account 208. Asindicated in FIG. 15, the additional funding source computer 1502 may bein data communication, at least from time to time, with the paymentservices provider computer 502.

For example, the payment services provider computer 502 and/or theadditional funding source computer 1502 may have capabilities fortracking all payment card transactions (e.g., both payment transactionsas described herein and conventional purchase transactions asillustrated in FIG. 1) initiated by the customer, and may detect when aparticular transaction, for which information is received from amerchant, is qualified to be partially funded by a loyalty program. Forexample, such a loyalty program may be operated by the customer'sissuing FI 206. Upon detection of a qualified transaction, the paymentservices provider computer 502 may send to the customer's mobile device204, along with the transaction information, an inquiry as to whetherthe customer wishes to apply a rewards payment to the pendingtransaction. If the customer assents, then a portion of the funds forthe payment transaction may come from the additional funding source1502, and the amount to be charged to the customer's payment cardaccount 208 for the payment transaction may be reduced by the amountsupplied by the additional funding source 1502.

In connection with split-funding transactions, the payment servicesprovider computer 502 may perform one or more of the following roles,among others: (a) acting as a control agent for the transaction; (b)acting as a storage facility for information and logic used (i) todetermine whether split-funding should occur, and (ii) to identifyfunding sources and to determine how to split the sourcing of fundsbetween the sources; and (c) initiating two or more payment transactionsto implement the split-funding transaction.

One manner in which a split-funding transaction takes place may be asfollows: (A) A request for the transaction is received by the paymentservices provider computer 502 from the customer's mobile device 204,with the request including for example the total amount to be paid and amerchant identifier. (B) The payment services provider computer 502 mayidentify the transaction as qualifying for split funding based on (1) anexplicit instruction from the customer or (2) the payment servicesprovider computer 502 recognizing predefined characteristics of thetransaction. (In the former case, the request from the customer mayinclude indications of the funding accounts and how the payment is to besplit between the accounts; in the latter case, the payment servicesprovider computer 502 may detect the qualification of the transactionfor split funding from one or more of the following attributes, amongothers: customer ID, customer payment card account number, merchant ID,merchant payment card account number, detail(s) of the items purchased,date and/or time, type of transactions, etc.) (C) After recognizing thetransaction as qualified for split funding, the payment servicesprovider computer 502 may temporarily suspend the transaction and thenmay access a database record or other stored information to determinehow to split the payment amount, and between what source accounts, andfurther may automatically seek and obtain any required approvals (e.g.,from a funding third party) or alternatively the funding third party mayindicate to the payment services provider computer 502 how much fundingthe third party will provide. (D) To the extent necessary, the paymentservices provider computer 502 may initiate funding authorizationrequests to verify that the indicated source account(s) have sufficientfunds to support the indicated payment transactions. (E) Next thepayment services provider computer 502 may initiate a respective paymenttransaction to implement each partial funding portion of thesplit-funded transaction. (F) Upon receiving confirmation that thepayment transactions have completed, the payment services providercomputer 502 may initiate a confirmation message to the customer and/orto the merchant (or alternatively confirmation to the merchant may comefrom the merchant's issuer.) In the event that one or more of thepayment transactions fails (e.g., due to insufficient funds or denial ofauthorization), the payment services provider computer 502 may take suchactions (depending, e.g., on stored instructions for such a situation)as (a) transmitting a message to the customer's mobile device 204 toreport the failed transaction (e.g., due to refusal to approve thetransaction by a third party or for reasons described above) andpossibly to ask the customer for an alternative funding source or forinstructions to default to an alternative manner (such as an alternativesplit-funding arrangement) of funding the transaction; (b) followingstored instructions to substitute an alternative funding orsplit-funding arrangement for the arrangement that failed.

Clearing and settlement of the constituent payment transactions may beundertaken in normal course and may in effect clear and settle theentire transaction. Split funding of transactions may not require anymodification of conventional payment transaction practices.Nevertheless, in some embodiments it may be useful to modify someconventional processes or provide new processes to facilitate handlingof failed transactions. Such processes may include reversals of paymenttransactions, establishment of rules of hierarchy as to funding sourcesand establishment of rules as to the order in which the constituentpayment transactions are to be executed.

In alternative versions of the system 200 c, the additional fundingsource need not be a loyalty program. One possible alternative is aproduct specific or merchant specific electronic coupon. As anotheralternative, and in the case of payment for medical or dental servicesor prescription drugs, the additional funding source may be a medical ordental insurance plan. For the latter case, the merchant device may, aspart of the transaction information transmitted to the payment servicesprovider computer 502, include claim information required by theinsurance plan, and that information may be passed on by the paymentservices provider computer 502 to the insurance plan as a request forcoverage of the payment. In some embodiments, such as the medicalinsurance example, the actual source of the additional funding may be apayment card account (not shown) issued by another issuer (not shown) tothe underwriter (loyalty plan, insurance plan, etc.) of the additionalfunding.

FIG. 16 is a block diagram that illustrates still another embodiment ofa transaction-handling system, indicated by reference numeral 200 d.

For example, the transaction-handling system 200 d of FIG. 16 may haveall of the components shown in FIG. 5, including the merchant device202, the customer's mobile device 204, the payment services providercomputer 502, the customer's issuing FI 206 (i.e. the FI which issuedthe customer's payment card account 208), the payment system 210 and themerchant's issuing FI 212 (i.e., the FI which issued the merchant'spayment card account 214). In addition, the system 200 d may includeanother payment card account 1602 (issued by issuing FI 1604), which isto receive a portion of the payment transaction, with the merchant'spayment card account 214 receiving the balance of the paymenttransaction. (Without loss of generality, it may equally be said thatthe merchant's payment card account 214 receives a portion of thepayment transaction, while the other payment card account 1602 receivesanother portion (or the “balance”) of the payment transaction.) Thepayment card account 1602 may be referred to as a co-recipient's accountin the sense that the party to which the payment card account was issuedis a co-recipient, with the merchant, designated in the paymenttransaction. Similarly, the issuing FI 1604 may be referred to as theco-recipient's issuing FI.

One manner in which a split payment transaction takes place may be asfollows: (A) A request for the transaction is received by the paymentservices provider computer 502 from the customer's mobile device 204,with the request including for example the total amount to be paid and amerchant identifier. In some embodiments, the request may specify thatthe payment be split and between which recipients. (B) The paymentservices provider computer 502 may identify the transaction asqualifying for or requiring split payment based on either explicitinstructions in the request or one or more rules triggered bycharacteristics of the transaction. (C) After recognizing that splitpayment is or may be in order, the payment services provider computer502 may temporarily suspend the transaction and then may access adatabase record or other stored information to determine how to dividethe payment, and between what destination accounts. (D) To the extentnecessary, the payment services provider computer 502 may initiate anauthorization request to confirm that sufficient funds are available forthe transaction in the customer's payment card account. (E) Next thepayment services provider computer 502 may initiate respective paymenttransactions to implement each partial funding portion of the splitpayment transaction. (F) Upon receiving confirmation that the paymenttransactions have completed, the payment services provider computer 502may initiate a confirmation message to the customer and/or to either orboth of the recipients of the payment transactions (or alternatively oneor both of the recipients may receive confirmation from the respectiveissuer for the recipient's payment card account). In the event that oneor more of the payment transactions fails (e.g., due to insufficientfunds or denial of authorization or unavailability of a recipientaccount), the payment services provider computer 502 may be guided bystored instructions to take appropriate action.

Clearing and settlement of the constituent payment transactions may beundertaken in normal course and may in effect clear and settle theentire transaction. Split payment transactions may not require anymodification of conventional payment transaction practices.Nevertheless, in some embodiments it may be useful to modify someconventional processes or provide new processes to facilitate handlingof failed transactions. Such processes may include reversals of paymenttransactions, and establishment of rules as to the order in which theconstituent payment transactions are to be executed.

There will now be discussed specific applications of the concept ofsplitting a payment transaction between two (or more) recipients.

In one example, the co-recipient is a sales tax collection authority.For example, the payment transaction requested by the customer may callfor the pre-tax subtotal amount of a sales transaction to be transferredto the merchant's payment card account 214, with the tax due on thesales transaction to be transferred (in the same or a related paymenttransaction) to the sales tax collection payment card account (referencenumeral 1602, according to this example).

In another example, it is assumed that the customer is purchasing anitem (e.g., a piece of furniture) that has been consigned for sale bythe merchant. In this case, the co-recipient is the consignor. Thus theconsignor's share of the purchase price is transferred to theconsignor's payment card account (reference numeral 1602, according tothis example) by a purchase transaction requested by the customer, andthe balance of the purchase price, which can also be considered themerchant's commission, is transferred to the merchant's payment cardaccount 214 by the same or a related payment transaction requested bythe customer.

In yet another example, the “merchant” is assumed to be a constructioncompany/home remodeling company that serves as a general contractor(GC), and the co-recipient may be a subcontractor or supplier ofmaterials to the GC.

In still another example, the “merchant” is assumed to be a part-timedomestic employee, and the co-recipient may be the Internal RevenueService or a state tax authority, acting as collector of payrollwithholding taxes or other payroll taxes.

FIG. 17 is a flow chart that illustrates a process that may be performedin the point of sale terminal 202 that may serve as the merchant deviceshown in FIG. 2, 5, 6, 15 or 16.

To summarize the import of FIG. 17 before discussing it in detail, insome embodiments the POS terminal 202 may be selectively operable ineither a conventional payment card purchase transaction mode (describedwith reference to FIG. 1) or in a novel mode, as described hereinabove,in which the POS terminal 202 serves as an adjunct to acustomer-requested payment card system payment transaction by which thepending sales transaction will be settled. As will be appreciated fromthe previous discussion (e.g., of FIGS. 2, 5 and 6), in the latter mode,the POS terminal 202 does not initiate a payment card purchasetransaction authorization request, but rather only displays or transmitstransaction information (to the customer's mobile device 204 or to anintermediary such as payment services provider computer 502) and thenawaits confirmation of the effectiveness of the customer-requestedpayment transaction.

Turning, then to FIG. 17, at 1702, information to define the purchasetransaction is entered into the POS terminal 202. This may entail, forexample, the barcode reader component 306 (FIG. 3) of the POS terminal202 being used to read a product identifying barcode or barcodes fromone or more items that the customer wishes to purchase.

Next, at 1704 in FIG. 17, the POS terminal determines whether it hasbeen placed in the (conventional) purchase transaction mode or in the(novel) payment transaction mode. If the former mode is selected, thePOS terminal operates (step 1706) in the manner described above withreference to FIG. 1. If the latter mode is selected, the POS terminaldoes not initiate a purchase transaction authorization request, butrather operates (step 1708) as described above in connection with FIG.8.

Selection between the purchase transaction mode and the paymenttransaction mode may occur in a number of ways. For example, in someembodiments, the purchase transaction mode may be selected by swiping amagnetic stripe payment card through the magnetic stripe readercomponent 310 (FIG. 3) of the POS terminal 202 or by bringing acontactless payment card or payment device (including, e.g., a mobiletelephone equipped with contactless payment device capabilities) intoproximity with the RFID/NFC terminal component 316 of the POS terminal202. In such embodiments, selection of the payment transaction mode mayrequire positive input from the operator, such as touching a relevantportion of a touch screen, actuating a soft key, or actuating adedicated function key to indicate selection of the payment transactionmode. In other embodiments, the payment transaction mode may be thedefault mode of operation for the POS terminal, entered upon initiationof a purchase transaction (e.g., by reading a barcode from a productitem), with the purchase transaction mode only being entered uponpresentation of a payment card or device to the POS terminal, asdescribed earlier in this paragraph. In still other embodiments,selection of either mode may require positive input from the operator,e.g., by selecting an appropriate option from a menu displayed by thePOS terminal.

(The above discussion is not meant to imply the absence of another modeor modes of operation, such as a cash payment mode.)

Departing from the above discussion of dual (or more than dual) useembodiments of the POS terminal 202, it should also be understood thatin some embodiments of the merchant device, whether or not it wouldgenerally be considered a POS terminal, the device may support only onemode of operation, namely a payment transaction mode as describedhereinabove in connection with FIG. 8. Alternatively, the merchantdevice 202 may support cash transactions in addition topayment-system-based payment transactions as described herein.

In some embodiments, the customer's mobile device 204 may also be a dualuse device in terms of its payment capabilities. That is, in someembodiments the customer's mobile device 204 may be selectively operableeither in a conventional contactless payment mode (in which the paymentcard account number is read from an RFID chip (reference numeral 424,FIG. 4) in the device by the POS terminal, which in turn initiates anauthorization request for a purchase transaction) or a paymenttransaction request mode of operation, as described hereinabove inconnection with FIG. 9. In some embodiments, the customer may select theformer mode simply by bringing the device 204 into proximity with theRFID/NFC reading component of a POS terminal 202. Selection of thelatter mode may require positive input from the customer, as byselecting a suitable menu option displayed by the display 402 of thedevice 204. In other embodiments, the latter mode may be enteredsemi-automatically, by receiving a message containing the transactioninformation, where the message is pushed to the device 204 by themerchant device 202 or by the payment service provider computer 502, andthe customer then responds affirmatively to the message to initiate therequest for the payment transaction.

In other embodiments, selecting either the purchase transaction mode orthe payment transaction mode for the customer's mobile device 204 mayrequire the customer to actuate a soft key, a dedicated button, or thelike.

In still other embodiments, the customer's mobile device 204 may takeits cue, in terms of selecting between the two modes, from a POSterminal 202 to which the mobile device 204 is presented. That is, ifthe POS terminal 202 is in the purchase transaction mode when the mobiledevice 204 is presented to the POS terminal's RFID/NFC component, thenthe purchase transaction mode may be automatically selected for themobile device 202, such that the mobile device uploads the payment cardaccount number to the POS terminal in a conventional manner in responseto a conventional interrogation signal from the RFID/NFC component.However, if the POS terminal is in the payment transaction mode, the POSterminal may respond to the presence of the mobile device at theRFID/NFC component by pushing the transaction information to the mobiledevice via NFC, and in response to receiving the transaction informationthe mobile device enters the payment transaction mode.

FIGS. 2, 5, 6, 11, 13, 15 and 16 each depict only system components thatmay be involved in a single transaction, rather than all of thecomponents that may be present in the system. For example, each systemmay also include: (a) numerous other customer mobile devices 204 inaddition to the one such device shown; (b) numerous other merchantdevices 202 in addition to the one such device shown; (c) numerous otherpayment card account issuers in addition to the two issuing FIstypically shown in the drawings; (d) numerous service providers inaddition to the service provider 1104 shown in FIG. 11; (e) numerousother employees and employers besides the single employee and singleemployer shown in FIG. 13; (f) a considerable number of additionalfunding sources in addition to the one shown in FIG. 15. Moreover, thevarious system embodiments shown in the drawings may be combined invarious combinations. For example, a single system may be provided whichprovides most or all of the features described with reference to FIGS.2, 5, 11, 13, 15 and 16.

In FIGS. 5 and 6, respectively, the confirmation of the paymenttransaction is shown as flowing from the merchant's issuer to themerchant directly and indirectly via the payment services providercomputer 502. Alternatively, however, the confirmation of the paymenttransaction may flow to the merchant via the payment system 210 and thepayment services provider computer 502.

To a large extent, the novel applications of payment transactions asproposed herein have been described in the context of face-to-faceretail sales of goods. However, a considerable number of other novelapplications of payment transactions are also contemplated. For example(and as briefly indicated above in connection with split payments, FIG.16), payment transactions may also be requested via a mobile device by apayment card account holder to settle payments for services such asautomobile rentals, taxi rides, airline and train fares, personal careservices (e.g., hair salon services, manicures, personal training,etc.), health club and gym fees, medical and dental services, drycleaning, home renovations, cultural and sporting event ticketing,periodical subscriptions, museum entrance fees, etc., etc. It is alsonot required that the merchant/service provider be face-to-face with thecustomer. Thus payment transactions may be initiated by the customer topay for telephone or online orders. For example, in the case where thecustomer's mobile device is a PDA, the customer may access an onlinestore, which may push the transaction information, upon checkout, to thecustomer's mobile device (possibly via a PSP computer 502). Thecustomer's mobile device may then request a payment transaction tosettle the online purchase. The online store may receive confirmationvia its issuing FI that the payment transaction is or will be completedbefore proceeding to fulfill the customer's order. The above-notedadvantage that the customer does not disclose his/her payment cardaccount number to the merchant may be particularly attractive in thecase of online purchases. Similarly, confirmed identification of themerchant (as per step 904, FIG. 9) to the customer prior to requestingthe payment transaction may also be a very significant, though optional,feature from the customer's point of view.

While many of the above examples of transactions implemented withpayment card system payment transactions have related to consumerpurchases, similar transactions may occur with respect to businesstransactions, such as purchases of supplies by businesses usingcommercial credit or debit cards, or, e.g., a small contractorpurchasing building materials with a credit or debit card. Thus acustomer, as referred to herein and in the appended claims, need not bean individual consumer.

In cases where there is a payment services provider computer to perform“on behalf” services as in the systems of FIGS. 5 and 6, the paymentservices provider computer need not necessarily perform all of theservices described. For example, in at least some situations, thetransaction information may be transmitted from the merchant device tothe customer's mobile device, or entered manually into the customer'smobile device, which then sends the payment transaction request to thepayment services provider computer for forwarding to the customer'sissuing FI.

In addition to other advantages, including those described above, thesystem architectures shown, e.g., in FIGS. 5 and 6 may also allow thecustomer's issuing FI to set policies for personalizing and/orcustomizing service practices, such that, for example: (a) credit offersmay be made only to certain customers and/or in connection only withcertain kinds of transactions; and (b) whether additional authenticationprocedures are required may be determined according to predeterminedrules on a customer-by-customer and/or on a transaction-by-transactionbasis. More complex rules may also determine when authentication isrequired, including for example rules based on recent transactionhistory for an account.

It will be understood that communications among the customer's mobiledevice 204 and/or the merchant device 202 and/or other components in thesystem may be carried, at least in part, via a conventional mobiletelephone network, which is not explicitly shown in the drawings.

In some embodiments, the customer's mobile device triggers the merchantdevice to download the transaction information to the customer's mobiledevice by transmitting a suitable signal to the merchant device, e.g.,by NFC. Correspondingly, the merchant device may download thetransaction information to the customer's mobile device in response toreceiving such a signal from the customer's mobile device. Receivingsuch a signal may place the merchant device in the above-mentionedpayment transaction mode of operation.

The flow charts and descriptions thereof herein should not be understoodto prescribe a fixed order of performing the method steps describedtherein. Rather the method steps may be performed in any order that ispracticable.

As used herein and in the appended claims, an “information message”includes a text message or any other message sent to or from a mobiledevice to transmit information other than audible or visual information.

As used herein and in the appended claims, “mobile identifier” refers toa mobile telephone number or any other identification information thatuniquely identifies a mobile telephone or other mobile device.

As used herein and in the appended claims, the term “payment cardaccount” includes a credit card account or a deposit account that theaccount holder may access using a debit card. The term “payment cardaccount number” includes a number that identifies a payment card accountor a number carried by a payment card, or a number that is used toidentify an account in a payment system that handles debit card and/orcredit card transactions or to route a transaction in a payment systemthat handles debit card and/or credit card transactions. The term“payment card” includes a credit card or a debit card (including apre-paid debit card). The term “payment card account” also includes anaccount to which a payment card account number is assigned. Thus apayment card account may include an account to which paymenttransactions may be routed by a payment system that handles debit cardand/or credit card transactions, even if the account in question is noteligible to be charged for purchase transactions or other transactions.A payment card account may also include an account from which paymenttransactions may be routed by a payment system that handles debit cardand/or credit card transactions, even if the account in question is notcustomarily used, or is not eligible, to be charged for purchasetransactions.

The account numbers that identify the merchants' or other recipients'payment card accounts herein may be in a format and in an account numberrange that allow payment transactions to be routed to the accounts inquestion; the accounts may, but need not, be operable also for chargingpurchase transactions to such accounts.

Although the present invention has been described in connection withspecific exemplary embodiments, it should be understood that variouschanges, substitutions, and alterations apparent to those skilled in theart can be made to the disclosed embodiments without departing from thespirit and scope of the invention as set forth in the appended claims.

What is claimed is:
 1. A method comprising: receiving, by a processorfrom a merchant device, transaction information comprising at least atransaction amount, merchant identifying information and customeraddressing information; transmitting, by the processor based on thecustomer addressing information, at least the merchant identifyinginformation to a customer mobile device; receiving, by the processorfrom the customer mobile device, a payment transaction request totransfer funds from a customer account to a merchant; translating, bythe processor, the customer addressing information into a customerpayment card account number and the merchant identifying informationinto a merchant payment card account number; and transmitting, by theprocessor, the payment transaction request to an issuer financialinstitution that issued the customer payment card account, the paymenttransaction request comprising the customer payment card account number,the transaction amount, and the merchant payment card account number. 2.The method of claim 1, further comprising receiving, by the processor,an authorization response from the merchant device, the authorizationresponse confirming validity and availability of the merchant paymentcard account.
 3. The method of claim 2, further comprising transmitting,by the processor to at least one of the merchant device and the customermobile device, a confirmation indicating that a funds transfersatisfying the payment transaction has occurred or will occur.
 4. Themethod of claim 3, wherein the merchant device is at least one of apoint of sale device or a mobile device.
 5. The method of claim 1,wherein the customer addressing information comprises a mobile telephonenumber.
 6. The method of claim 1, wherein the transaction informationfurther comprises a transaction reference number generated by themerchant device, and wherein the payment transaction request includesthe transaction reference number.
 7. The method of claim 1, furthercomprising, subsequent to receiving the payment transaction request,requiring, by the processor based on at least a portion of thetransaction information, completion of an authentication procedure priorto transmitting the payment transaction request to the issuer financialinstitution.
 8. The method of claim 7, wherein the at least a portion ofthe transaction information comprises at least one of the transactionamount, a time of day, a day of the week, an item associated with thepayment transaction, a customer identity, a merchant identity, recentcustomer account activity, and past customer account activity.
 9. Themethod of claim 7, wherein the authentication procedure comprisesreceiving, by the processor, confirmation from the issuer financialinstitution that an exchange of messages between the customer mobiledevice and the merchant device was successfully completed.
 10. Themethod of claim 1, further comprising, after receiving the paymenttransaction request: detecting, by the processor based on thetransaction information, that the payment transaction qualifies forpartial funding equal to a partial funding amount from at least oneadditional funding source; transmitting, by the processor to thecustomer mobile device, a request to apply the partial funding amountfrom the at least one additional funding source to the transactionamount; receiving, by the processor from the customer mobile device, apositive response; and reducing, by the processor, the transactionamount by the partial funding amount before transmitting the paymenttransaction request to the issuer financial institution.
 11. The methodof claim 10, wherein the at least one additional funding sourcecomprises a loyalty program.
 12. An apparatus, comprising: a processor;a communication device operably connected to the processor; and astorage device operably connected to the processor, wherein the storagedevice stores non-transient instructions configure to cause theprocessor to: receive transaction information from a merchant devicecomprising at least a transaction amount, merchant identifyinginformation and customer addressing information; transmit, based on thecustomer addressing information, at least the merchant identifyinginformation to a customer mobile device; receive a payment transactionrequest from the customer mobile device to transfer funds from acustomer account to a merchant; translate the customer addressinginformation into a customer payment card account number; translate themerchant identifying information into a merchant payment card accountnumber; and transmit the payment transaction request to an issuerfinancial institution that issued the customer payment card account, thepayment transaction request comprising the customer payment card accountnumber, the transaction amount, and the merchant payment card accountnumber.
 13. The apparatus of claim 12, wherein the storage devicefurther comprises instructions configured to cause the processor toreceive an authorization response from the merchant device, theauthorization response confirming validity and availability of themerchant payment card account.
 14. The apparatus of claim 13, whereinthe storage device further comprises instructions configured to causethe processor to transmit to at least one of the merchant device and thecustomer mobile device, a confirmation indicating that a funds transfersatisfying the payment transaction has occurred or will occur.
 15. Theapparatus of claim 12, wherein the storage device further comprisesinstructions configured to cause the processor to receive a transactionreference number generated by the merchant device, and to transmit thetransaction reference number with the payment transaction request. 16.The apparatus of claim 12, wherein the storage device further comprisesinstructions configured to cause the processor to require completion ofan authentication procedure before processing the instructions totransmit the payment transaction request to the issuer financialinstitution.
 17. The apparatus of claim 16, wherein the instructions forrequiring the authentication procedure further comprises instructionsconfigured to cause the processor to receive confirmation from theissuer financial institution that an exchange of messages between thecustomer mobile device and the merchant device was successfullycompleted.
 18. The apparatus of claim 12, wherein the storage devicefurther comprises instructions, subsequent to the instructions forreceiving the payment transaction request, configured to cause theprocessor to: detect that the payment transaction qualifies for partialfunding equal to a partial funding amount from at least one additionalfunding source; transmit a request to the customer mobile device toapply the partial funding amount from the at least one additionalfunding source to the transaction amount; receive a positive responsefrom the customer mobile device; and reduce the transaction amount bythe partial funding amount before processing the instructions totransmit the payment transaction request to the issuer financialinstitution.